fix(studio): undo paints a move or nudge back at once while its save is still running - #4877

What

If you press Cmd+Z while a move or a nudge is still saving, the box now jumps back to where it was in the same frame as the key. Before, it stayed at the moved place until the save and the server's undo had both landed. Under load that was often a second or more, so a drag started from what was on screen then jumped.

Why

Undo's instant paint (from #4798) predicts the step from this tab's history and shows it in place. An edit that is still saving has no history entry yet, so the prediction would show the edit before it, and the paint is refused. The screen then waited for the server.

The same gap stayed open briefly after each save: the save ended before the history list holding its entry had been fetched, so for that moment the edit was neither pending nor known to the history.

How

• A pending edit can now carry a live revert: a function that shows the edit undone and returns one that shows it again.
• The canvas move (single and group) and the arrow-key nudge burst register their saves as pending edits with a revert. The revert puts the moved elements back at their offset from the start of the gesture. Elements GSAP positions have no revert, so they still wait as they do today.
• When the instant paint is refused, undo paints the newest pending edit back, in the key's own task. Only the newest is painted: one Cmd+Z undoes one edit. A second Cmd+Z while that edit is still saving paints nothing and waits.
• If the server step fails or steps nothing, the edit is shown again.
• A nudge burst that undo painted back while it was still waiting for keys is still saved, so the server can undo it, but its commit no longer draws it again.
• Anything an edit starts inside its own registration (the tracked context action, a GSAP commit) counts as part of that edit, not as a newer one. An edit whose start throws ends its registration, so it cannot hold up later undos and exports.
• recordEdit now waits for the history list it fetches after a claim. A save therefore ends only once undo can predict it, which closes the gap above. The fetch was already requested after every claim (void refresh()); it is now awaited, so there is no extra request, and a save ends when that fetch returns instead of before it.
• Bench: undo and a text step's Enter now wait a frame before the next step reads the box, as a nudge already does per key.
• seqrepeat-none-px-r0-nested-z100 and sequndo-none-px-r0-root-z100 are out of the quarantine list. The quarantine list is now empty.

Why the bench needed the frame

The drag that follows an undo read the box with CDP DOM.getContentQuads 0 to 4 ms after Studio had already moved it back in the DOM. In the failing runs that read still returned the spot before the undo, while getBoundingClientRect on the same element right after returned the spot after it. Reads that passed had a frame between the undo and the read.

So the bench pressed where the box had been before the frame that showed the undo. Two frames later, at mouse down, the box was no longer there, and the press started no drag. Before this PR the box stayed put until the server's undo, which hid the race.

Bench

On one machine, 3 jobs, three runs of each build, with this branch's bench:

Both builds pass every run once the bench waits for the frame, so this table shows no regression; it does not measure the gain. The gain is how soon the box shows undone, which is in the captures below. "This PR" is the build one commit before the head; the only later change removes a code comment. In CI the gate passes, with nothing newly passing or unbanked: main's baseline already banks both ids taken off the quarantine list as passing.

Test plan

• studioPendingEdits.test.ts: only the newest edit is painted back, once, and shown again on request; nothing is painted when the newest edit has no revert; what an edit starts inside its registration is part of it; an edit whose start throws ends its registration. The last fails when a throwing start does not end the registration.

• dragUndoPaint.test.ts: a drag whose save is still running can be painted back at once and shown again, and stops counting once its save lands. Fails when the drag registers no revert.

• useEditHistoryActions.paint.test.tsx, over the real history engine:

  • an undo pressed while a nudge's save is queued shows the nudge undone in the key's own task, and the file and the box end undone;
  • an undo inside the nudge's wait shows the nudge undone at once, and the burst's commit doesn't draw it again.

  Both fail without the revert paint; the second also fails when the burst's commit redraws it.

• usePersistentEditHistory.test.ts: with the history list slowed by 50 ms, the step is predicted as soon as the save ends. Fails when recordEdit does not wait for the list.

• Bench unit tests (tests/e2e/edit-accuracy), the Studio suite, typecheck, oxlint, oxfmt.

Before

A move in a bench fixture with every save slowed to 1.5 s, Ctrl+Z on the frame after release, on #4807: the box stays at the moved place until the server's undo lands.

After

The same on this branch: the box is back in the first frame after the key and stays there.

How to read the panels: each one is the last frame the browser's screencast sent at or before that time. The screencast sent no frame between 107 ms before the key and 107 ms after it, so the "50 ms after" panel repeats the frame from before the key. The first frame after the key, at 107 ms, already shows the box back at its start; the selection outline has caught up by the next frame it sent, at 209 ms. The strip cannot show how soon the box paints. That comes from the tests, which check that the box is back in the key's own task. The capture was taken on a build of the first commit of this branch; later commits change neither the move nor its revert.